In every periodically running system, program sections (processes, tasks) are executed cycle by cycle, in succession. In programs having an OSEK operating system (operating system that is used primarily in microcontroller systems), for example, a monolithic kernel made up of the operating system and application is generated. The application is subdivided into multiple tasks. These have a priority, and their status may be either cooperative or preemptive. According to priority, preemptive tasks may actively interrupt lower tasks at any point. Interrupted tasks continue their processing after the execution of the preemptive task has terminated. Cooperative tasks are not able to interrupt other tasks. They begin once a task has run. The waiting task having the highest priority starts. The temporal end of a task is thus reached at different rates after its activation, as a function of its priority.
One or multiple processes are defined in one task. A process is a sequence of instructions that, depending on the scheduling strategy, may be interrupted (by preemptive tasks) or not (by cooperative tasks). All processes of a task are executed sequentially.
If the totaled runtime of the tasks is greater than the cycle duration (system cycle duration), this is referred to as overrun. The time provided was thus not sufficient to execute all tasks. When designing the software, a programmer should ensure that such a case is not able to occur. In practice, the cycle duration selected is so large that the tasks have sufficient runtime available to them. However, it is problematic if the runtime of the individual tasks is variable.
In addition to an extension of the task runtime being determined by computing time, such extension may also be caused by an unforeseen state. If the task is unable to leave this state on its own, this is called a “hang-up.” An example of this is an infinite loop. A continued execution of the task is then no longer possible. Such a hang-up disturbs not only the running of the task, but in certain instances also the entire program run. Depending on the priority of the task, this may even mean a hang-up of the program.
In the following, reference is made primarily to automobile manufacturing, without the method being limited to this application.
Panoramic view applications in motor vehicles are normally based on signal-processing software that enables the provision of information about the surroundings of the motor vehicle. Sensors, such as video, ultrasound or radar sensors, monitor the surroundings of the motor vehicle. The signals of these sensors are transmitted to a central processing unit, typically a control unit, where these signals are conditioned for applications such as parking assistance, airbag activation, ACC (adaptive cruise control, “intelligent cruise control”), etc.
The signal-processing algorithms are computer-intensive, and the processing time is directly dependent on the surroundings to be monitored. Thus, computer-intensive surroundings scenarios, temperature fluctuations, or sensor measurement malfunctions may possibly utilize the microprocessor to capacity, as a result of which other computing tasks may no longer be executed.
The general objective of a runtime monitor is to provide trapping mechanisms as a function of the processing time of the signal processing in order to be able to reliably design safety-critical systems.
Runtime monitors exist, known in software technology as “watchdog,” that react to a runtime violation by restarting the system. In this context, this is typically a device or software functionality in microcontroller-controlled electric devices, which prevents a runtime violation of the software from causing a complete malfunction of the device.
This is typically achieved by the software notifying the watchdog at regular intervals that it is still functioning properly. If, as a result of an error, the execution of the program is discontinued (crash or hang-up of the program), this message is not sent. As a result, the watchdog returns the device to a defined initial state by resetting it (reset).
The device cannot be used during the time of the reset and thus is not able to process data or react to queries. This is a disadvantage in particular for safety-related applications. For example, a “precrash” application attempts to detect collisions with other objects in advance and takes appropriate measures (seat-belt tensioner, airbag, etc.) to protect possibly the life of the occupant. For this reason, it is important and desirable that systems of this type are always in working order.
Thus, the problem arises of specifying a method and a device for improving the operation of microprocessor systems.